Josh Sutphin
GamesMusicWriting         

Conquistador

A screenshot from Conquistador, depicting a narrative event in which the ship is caught in a tropical storm.

About the Game

Conquistador was my entry for Ludum Dare 17, a 48-hour game development competition based around the theme of “Islands”. It placed #34 (out of 204 entries), putting it in the top 20% of submissions overall.

In Conquistador, you play an explorer in the Age of Sail: outfit your ship and crew and set sail in search of uncharted islands, buried treasure, and mythical creatures!

Postmortem

A screenshot of the welcome dialog from Conquistador, which briefly explains the concept of the game.

48 hours is not a lot of time to make a game, so you have to be very, very careful when you initially scope it out. When the theme of "Islands" was announced, I spent about two hours thinking about the theme and possible approaches to it before settling on this design, what I'm tentatively calling a "random event game". It's kind of a short-form roguelike. The short-form part is self-explanatory, but the roguelike part is very specific in that it features permadeath and a "we move" system. "We move" just means that every time you move, everyone else moves too... in normal roguelikes, "everyone else" means the monsters, but in Conquistador, it really just refers to the storm.

What I added to the formula is the "random event" bit, which just says that every move has a chance to trigger an event. Events are simple multiple-choice questions, presented with text and a static image, and when the player makes a choice -- much like a Choose Your Own Adventure book -- you're branched off to either some other part of the event, or the conclusion of the event. There's also some under-the-hood dice rolls to determine how certain choices play out, like whether firing cannons at the pirate ship succeeds or fails. These dice rolls take certain modifiers into account, which usually means making multiple rolls against the same success chance depending on how many crew members of the relevant type you have (e.g. deckhands for ship maneuvers, engineers when operating the cannons, etc.)

What I subtracted from the standard roguelike formula is a lot of the procedural complexity and deep rulesets. The game mechanics in Conquistador consist solely of random events and a simple list of resources including treasures, weaponry, and crew.

These decisions left me with a pretty scope-light game, actually. The list of resources is just a list of integers under the hood, and an event is just a Unity GameObject with some parameters for what image to display, the description text, and an arbitrarily-sized array of strings for the choices available. Events are defined by an abstract base class which implemented a virtual function HandleEvent; specific events derived from that class and overrode that function, receiving a 0-based index referring to the player's selection and handling that however it wants.

A screenshot of the main game screen from Conquistador: a tile-based map with a few small islands, the player's ship, and a nearby storm.

The world model is exceedingly simple as well: an 8x7 tile grid with a player-controlled ship and an AI-controlled storm. Only one tile -- the home port -- is guaranteed, and it is generated at the beginning of time, surrounded on all eight sides by open sea. Beyond that, all tiles are "unexplored", which is a distinct tile type. When the player reveals a tile, a random selection of islands (or open sea) is chosen and replaces the revealed tile. These selections are defined by a probability spread that basically weights each type, so even though there are nine island types and just one open sea tile, you still see open sea most frequently (the same probability spread concept applies to events with respect to specific island types, although I didn't have time to tune those spreads so they're effectively just cloned across the board).

I pretty much worked out all of the above in those first two hours of focused concept development. On Saturday I started implementing, and by Saturday night I had everything in except the events themselves. The underlying event system was hooked up, but the individual events had yet to be scripted... but I did have the player-controlled ship, the resource and crew models, the world model, the exploration mechanic, and much of the UI in place.

Sunday morning I blitzed out a handful of test events, and it was only at that point that the game design was finally validated. Which is probably a bit late to validate your design when you're on a 48-hour time constraint, but neither the design nor the tech were particularly risky, so it wasn't that big of deal. Things did finally start to break down, however, while I was scripting up the pirate ship attack, which is the most complex event in the game.

All the other events are pretty simple: you're presented with a choice, you pick one of 2-3 options, and the event terminates accordingly. One or two events feature a second choice depending on how the first one went. The pirate ship attack can be as long as five choices, depending on how you navigate the flow, and scripting its logic using the event authoring paradigm I'd established was pretty much a nightmare of nested switch statements and general cognitive pain. This all stemmed from my decision on Saturday that it'd be a good idea to handle player choices by modifying the active event's flavor text string and choices array on the fly... a decision whose wisdom now eludes me.

Most events took 10-20 minutes to script, write, and create splash art for. The pirate ship attack took about three hours. As a result of that massive time sink, I ended up having to cut several intended features:

These features were progressively cut as the deadline drew nearer, to ensure that I'd have enough time left to tie up loose ends, fix bugs, add some audio (I ended up with just a looping music track and no sound effects), and apply a little bit of polish. I made a big deal of securing an hour at the end for polish, because polish is usually the first victim of time-constrained competitions like this and I felt that taking that time would help the game stand out from the crowd, even if the overall feature set turned out to be less ambitious as a result.

A screenshot of the failure screen from Conquistador, indicating that the mission was abandoned and enumerating the player's monetary losses as a result.

A special note about the writing, which you'll notice is tonally all over the map right now. Originally I planned to take the game fairly seriously, evoking themes of mystery and wonder, the call of exploration and the thrill of discovery... pretty much a romanticized take on the Age of Sail. As I was blitzing out events on Sunday afternoon, with the contest deadline drawing uncomfortably close, I couldn't justify spending much time on first drafts, so I just pounded out whatever text came to mind so I could move on to the next event and reach something resembling a critical mass, because this game lives and dies on event variety (and by the way, there's nowhere near enough events to really sell the experience I was going for, but such is the way of 48-hour game design competitions).

As a result of this flying-by-the-seat-of-my-pants event writing, and as I became increasingly desperate to just get something done so I could wrap up the game in time for submission, I ended up with a few hilariously awful lines. I intended to come back around for a second pass during my "polish hour" to tighten up the writing and bring all the events in line with a consistent tone, but by the time I got to that point I found that there was something endearing about the borderline-silly way these otherwise-serious events were being presented, and I ended up leaving the hilariously awful lines in. Thus far, the response to these has been surprisingly positive.

The best thing about Ludum Dare -- this, by the way, was the first time I've participated in this event -- is that the 48-hour time limit is actually liberating. It seems so harsh at first, but in a stroke of counterintuitive brilliance, it forces your internal critic to just shut the hell up and let you make whatever strikes your fancy. There is no time for second-guessing, no time for critical analysis and comparison and "what if" scenarios. You just go with your gut... and it works, because you know that if you fail, you're only out a weekend, and that's not really much of a cost at all.

Created 11/12/2022 • Updated 11/29/2023